For optimal viewing experience, streaming video over a network should take into account the prevailing network conditions to provide the optimal viewing experience by dynamically adjusting to changes in network throughput that impact streaming video performance. An HTTP Live Streaming (HLS) encoder encodes a video into a plurality of different bit-rates or streams, with each encoding being segmented into a set of small video files. Typically each video file is a 2 to 10 second in duration. Each output video stream from an HLS encoder will be encoded at a number of bit-rates, for example into a low (64 kb/s), medium (640 kb/s) and high bandwidth (3000 kb/s) encoding, each of which is segmented into files of a predetermined length, for example 10 second long video segments per file. A client may stream the video by requesting the first file of the appropriate bit-rate depending upon the prevailing or estimated network conditions. Once the requested video file is received, it is played and the next video segment requested.
FIG. 1 depicts an illustrative prior art system for streaming video over a network using Hypertext Transfer Protocol (HTTP) in a content distribution network (CDN). The system 100 receives a video stream 102, at an encoder 104. The encoder 104 receives the video stream 102 and encodes the video stream into a plurality of individual video segment files of different bit-rates. As depicted in FIG. 1, the encoder 104 produces a plurality of bit-rate encodings 106a, 106b, 106c (referred to collectively as bit-rate encodings 106) of the video. As depicted, each bit-rate encoding is segmented into a number of individual files, depicted by the individual boxes of the bit-rate encodings 106. Each individual file represents a particular segment of the video. The segment duration of each individual file is identical across all encoded bit rates enabling an HTTP client to easily switch to a different bit-rate encoding in response to a change in network conditions.
Typically an HLS encoder 104 can only output the bit-rate encodings 106 to a very limited number of publishing points, for example one or two locations. As the encoder 104 produces each of the individual files for the different bit-rate encodings 106, they are transferred to a distribution network 108. The files of the bit-rate encodings 106 are transferred to one or more publishing points over a distribution network 108 using a transfer protocol, which is typically HTTP, although other protocols for transferring files could be used, such as file transfer protocol (FTP). Additionally or alternatively the files for each bit-rate encoding 106 may be written to an Network File System (NFS) storage device that is accessible by one or more publishing points. The distribution network 108 receives HTTP requests, such as an HTTP GET request, from one or more client devices 110, 114, 118 for individual files of the bit-rate encodings. The distribution network 108 then sends the requested file segment to the requesting client. As such, a client device can change the bit-rate of the video being streamed by requesting a file for the video segment of the same time interval which contains the optimum encoded bit rate based on current network conditions as determined by the HTTP client. In FIG. 1, all of the segment files 112 requested by, and returned to, the display device 110 are depicted as the high bit-rate encoding, while all of the segment files 116 requested by, and returned to, the display device 114 are depicted as the low bit-rate encoding. Display device 118 is depicted as requesting and receiving segment files from different bit-rate encodings, as such, the bit-rate of the video displayed on the device 118 will vary. Although depicted as a single server, it will be appreciated that the distribution network 108 may be provided by a plurality of servers that co-operate to respond to HTTP requests. As will be appreciated, the encoder 104 may transfer the bit-rate encodings 106 to a cache gateway, which receives and responds to HTTP requests from edge caching servers. The edge caching servers in turn may respond to HTTP requests received from display devices. The edge caching servers may cache file segments for a short period of time so that if a further device requests the same segment, it can be provided from its cached version instead of sending an HTTP request to the cache gateway for the segment. A cache gateway may be a bottleneck if it does not have sufficient bandwidth or processing capabilities to respond to all of the HTTP requests received from different edge caching servers. If the cache gateway cannot service all of the requests as required, it may be necessary to add one or more additional cache gateways. Adding additional cache gateways may in turn require one or more additional encoders in order to be able to provide sufficient outputs to the additional cache gateways.
It is desirable to have a system for distributing video via HTTP that does not require additional video encoders to service an increased number of requests for streaming the video.